Typical error and event codes are a set of pre-defined values that are used to identify specific events and/or errors in a system. They are used to define abnormal states and their purpose is to provide an easy method to allow the presence of such a state to be communicated to an operator. Examples of typical error and event codes include codes, messages, and strings. Codes are usually represented by numbers while messages and strings are represented by text and possibly numbers.
As electronic devices (and systems) become more and more complicated, the possibility of events, such as errors, warnings, and other conditions, occurring in connection with such devices also correspondingly becomes greater and greater. These events are generally related to, for example, the operation of the device, the software that powers the device, and the user operation of the device.
Moreover, as the complexity of a device increases, the number of possible events and/or errors which can occur also increase accordingly. With the proliferation of the number and occurrence of possible events and/or errors, a comprehensive system keeping track of all possible events and errors becomes very difficult to develop. Nevertheless, error and event codes have been developed in an attempt to facilitate the identification of events and/or errors. However, codes which have been developed to date have many shortcomings.
Error and event codes developed to date generally fail to follow a standardized format. Because test programs are most likely written by many people independent of each other, the same event can be characterized differently. This is because the format of the error and event codes is usually left to the discretion of the designer and/or programmer. As a result, two different designers may use two different formats when they are designing a code for the same event.
To overcome the non-standardized format problem, an approach which specifies a pre-defined set of error and event codes can be used. This approach works well when the codes that are pre-defined reflect all possible errors or events. However, this approach does not work well in an environment where there is constant innovation that renders error and event code definitions obsolete within a relatively short period of time. Additional difficulties which renders this approach less effective include the problem of disseminating information about the error and event codes to multiple designers, and the problem of setting up a comprehensive set of error and event codes for all events.
Also, even if a set of error and event codes could be developed to encompass all known events, programmers working on different portions of a test program might categorize the same error differently and thus use different codes for the same error. Additionally, new errors could be found that are not in the set. New error and event codes could be developed but the new codes might not be disseminated fast enough and might cause problems for development that has already been coded. Thus, a rigid pre-defined set of error and event codes would not be fully compatible with the development process.
Furthermore, error and event codes developed to date generally do not provide sufficient information to allow the specific location of the event to be identified. These codes merely inform the outside world that an error and/or event has occurred but do not otherwise supply further information to allow a troubleshooter to easily pinpoint the location of the problem. Most likely, due to the complexity of most devices which exist today, a user would not know how to troubleshoot an error by merely knowing that an error has occurred. Thus, a code merely informing a user that an error has occurred would not be helpful.
Finally, these codes also do not provide any directions as to how to remedy an error or otherwise take steps to satisfy an event. The solution to an error is oftentimes relatively more valuable than having the knowledge that an error has occurred.
The present invention generally relates to event codes. More specifically, the present invention relates to an improved and extensible event code. An event code designed to identify an event is provided.
In an exemplary embodiment, the event code of the present invention includes a set of predefined values and an optional set of implementation-driven values. The set of predefined values inform a user what kind of event has occurred and identify the various components which are related to this event. The set of predefined values further inform the user which of the various identified components are likely to have caused the event.
More specifically, the set of predefined values is collectively represented by a number of fields including: a severity ID, an originator ID, an event class, an event cause ID, an instance ID and an event location ID. The severity ID is used to provide information concerning the severity of the event. The originator ID is used to indicate where the event originated. The event class identifies the nature of the event. The event cause ID identifies what hardware, software, or other component is related to the event. Instance ID provides information on the specific instance of hardware, software, or other component that is related to the event. Event location ID provides information on what is believed to be the cause of the event.
Optionally, the set of implementation-driven values provides additional reference information which better enables the user to analyze the event. Additional self-help information is also available which may assist the user to address the event. Finally, the set of implementation-driven values optionally include a self-fix connection which the user can select to activate certain self-fix process(es) to automatically address the event.
More specifically, the set of implementation-driven values is collectively represented by a number of fields including: a code reference ID, reference data, a self-help connection, a self-fix connection and self-fix data. The code reference ID contains reference information that shows the specific location in a module that found or caused the event. The reference data includes reference information that can be used to troubleshoot or debug the event. The self-help connection identifies information about the type of event that is detected. The self-fix connection includes a connection to one or more self-fix process(es) that can be used to automatically address the event. The self-fix data includes data to be used in connection with the self-fix process(es) initiated by selection of the self-fix connection.
Reference to the remaining portions of the specification, including the drawings and claims, will realize other features and advantages of the present invention. Further features and advantages of the present invention, as well as the structure and operation of various embodiments of the present invention, are described in detail below with respect to the accompanying drawings. In the drawings, like reference numbers indicate identical or functionally similar elements.